Playtesting kovarex We have been playtesting a few days this week. There were some things we had to fix on the fly, but we still were able to play quite a lot, so I would say that it went surprisingly well. We have been able to get 3 multiplayer bases into a late game stage.
The release plan (kovarex) This week was the time to close and finish all the things that will go to 0.17.0. Not all of the things that we originally planned to be done were done (surprise), but we just left any non-essential stuff for later so we won't postpone the release any further. The plan is, that next week will be dedicated to the office playtesting and bugfixing. Many would argue, that we could just release instantly and let the players find the bugs for us, but we want to fix the most obvious problems in-house to avoid too many duplicate bug reports and chaos after the release. Also, some potential bugs, like save corruptions, are much more easily worked on in-house. If the playtesting goes well, we will let you know next Friday, and if it is the case, we will aim to release the week starting 25th February.
For a few frames more Previously on Factorio Friday Facts (#264): "No wonder, scenes heavy on smoke or trees can tank FPS, especially in 4K. Maybe we should do something about that..."
Hello, as we learned countless time before: Visual feedback is the king! Especially when the GUI is as complex as the Train GUI.
It's finally here (Twinsen) The proposal was first mentioned more than 1 and a half years ago, in FFF-191. Since then, we kept mentioning it in our blog posts and players kept asking about it. After a lot of back and forth within the team on whether we should implement it or not, and how it should work, we finally have it almost finished for 0.17.
GUI progress update (kovarex) This is a continuation of the last status report from FFF-269. As it might not be a surprise, the biggest bottleneck of the 0.17 release is the GUI. I like to believe, that we have learned a lot from the pitfalls of the collaborative creative process of GUI. This is the typical way we were redesigning the GUI: Two to three people started discussing what could be cool to change in the particular GUI. Some people randomly joined and left the ongoing discussion. Arguments to discard certain ideas have to be repeated over and over. Then the discussion is ended because of something. A week later people start talking again, most of them forgot most of the stuff, or were discussing it with different people, so they assume some details of the changes to be understood by everyone, while they aren't. They come to an agreement how it should be done. They have a random discussion about it a week later and figure out, they had completely different ideas about how it should be done, they just didn't articulate them precisely. Both are kind of angry to have to reopen and re-negotiate the subject again. Someone starts to implement the GUI, but half-way through it is uncovered, that there was another layer of misunderstanding when specifying how should the work be done, and we need to go to step 1 again and repeat. Since many GUIs are thought and worked on in parallel, these situations overlapped and amplified the problems of mixing things up in our heads about what we agreed on in which GUI. Luckily, we eventually figured out, that it can't be done like this, and since there is a lot of work in the GUI, we need to make a process. It goes like this: First, there is some general discussion about the GUI, all team members can share their ideas. kovarex + Twinsen sit alone in the office, and discuss for some time (can be hours), all the pros and cons of how things should be done, and make some agreement. Twinsen writes a detailed UX document about the GUI containing the structure, and more importantly the behaviour, in a detailed manner. Twinsen + kovarex discuss the UX document and propose changes until they agree on the final version. Albert + Aleš take the UX document and create a UI mockup based on it. kovarex + Twinsen + Albert agree on the UI mockup or propose changes. Someone is assigned to implement the GUI based on the UX document and UI mockup kovarex reviews that the implementation is correct and points out some inconsistencies that he can see. Part of this step is making sure, that we share as many GUI styles and code as possible across different GUIs. kovarex + Albert have a final look on the implementation and fix final details until they both agree that the screen is fully finished. Having the UX documents/UI mockups always available proved to be a huge time saver. Not only it helps us to solve the communication problems, we also don't have to remember and re-articulate decisions from some time ago as we can just open the document and see what we agreed on and instantly continue where we left off. A good part of this strict pipeline is that we now have better knowledge of the state of the work progress. These are the GUI screens that we hope to deliver for 0.17: .header_cell { text-align:center; font-weight: bold; } .finished { text-align:center; font-weight: bold; } .not_finished { text-align:center; font-weight: bold; } .finished_gui_table { border-spacing: 10px; } .finished_gui_table td { border: 1px; border-style:solid; padding: 5px; } General UX UX draft UX review UI mockup UI review Implementation draft Implementation review Final review Load map Save map Graphics settings Control settings Sound settings Interface settings Other settings Map generator Technology GUI Technology tooltip Recipe/item/entity tooltip Action bar Shortcut bar Train GUI Manage/Install mods Main screen chat Recipe explorer Character screen Menu structure New game Help overlay Chat icon selector Blueprint library You can see, that there is still a lot of to do, but the work tends to accelerate as more and more of the GUI layouts/tilesets/standards are being finalized and reused. The conclusion is that 0.17 experimental in January is possible, but it might be February as well :).
Hello, the office is slowly ramping back up after the Christmas and New year festivities.
It's the last Friday of 2018, and as such the last Friday Facts before the New year of 2019. We all hope everyone has had a great 2018, and looking forward to a lot more automation fun to come in 2019. Albert has produced a postcard for you all to share to give the year a good send-off.
New Fluid system 2 (Dominik) Hi Factorians, Here is Dominik, with an update on the fluids. This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features. In FFF-260 I wrote about how it all started, why we are doing it and what the plan is. There was a huge response from you all and I want to thank everyone for their contributions. Let me apologise to redditors, as at the beginning I started responding on the forums and when I realized there is reddit too, there were too many comments for me to handle. The forum users produced many ideas on how the system could work. About third of them was a fluid teleportation, many where known but many were entirely new and interesting. What intrigued me was the large variety of backgrounds they came from - differents kinds of engineers (mechanical, CS, electrical, ...), mathematicians, physicists, and even people with real pipes hands on experience. I won’t go through them here, you can find them on the forums or reddit. There were two proposals on the forum though that were so good that they made it into the game - from quinor and TheYeast. Both of these proposals were very similar and kinda similar to the previous game logic. What it shares is that the mechanic still uses fluid physics simulation and volume in a pipe as a base for the movement calculation. As a result, not much changes on the first glance. What they add though is an emphasis on the fluid network update being independent on the current state (i.e. updating one pipe only depends on state from the last tick) and is therefore independent on evaluation order, which was one of the big pains of the old model that led to sometimes ridiculous junction behavior. Difference between these two was rather small - quinor’s version allowed perfect throughput with 3 passes over the fluidboxes (fluidbox is the thing managing fluids for entities, so I will talk about them), while Yeast’s one was 2 pass with ¼ throughput. What was outstanding though is that TheYeast, a physicist, supported the model with a nice theoretical background and what’s more, he made an amazing JS simulator to test and compare various modification of the model. Because that extra pass in quinor’s version was too high a price for the perfect throughput, I went with TheYeast’s two pass one. Since the old algorithm only used a single pass run by entities for the update, I first needed to overhaul the whole system to allow accommodating the new one. Going from one pass to two passes necessarily means higher complexity, so we made a big effort to optimize everything we could to make sure we will still end up faster than 0.16. Kovarex wrote about it in FFF-271.
